AWS ParallelCluster CloudFormation のスタック作成速度向上によりクラスターのデプロイ速度は早くなったのか確認してみた
AWS ParallelCluster のクラスターのデプロイって地味に時間かかるような印象はありませんか?
先日のアップデートで CloudFormation のスタック作成速度が早くなりました。クラスターのデプロイ速度に変化はあるのか確認してみました。
検証結果まとめ
- 同じクラスターのコンフィグを用いて今と昔のクラスターのデプロイに要した時間を比較しました
- デプロイ完了までの時間は昔と比べると 1 分短縮され、約 11% の速度向上を確認できました
項目 | 旧 | 現在 | 差分 |
---|---|---|---|
開始時間 | 2023-12-27 11:59:14 | 2024-03-19 12:55:06 | - |
終了時間 | 2023-12-27 12:08:13 | 2024-03-19 13:03:05 | - |
時間差 | 8分59秒 | 7分59秒 | 1分0秒 (現在が早い) |
ParallelCluster と CloudFormation の関係
pcluster
コマンドではクラスター環境を作成する裏側では AWS CDK により CloudFormation テンプレートが作成されています。要は CloudFormation でクラスター環境一式を作成しています。
今回の CloudFormation スタック作成速度向上は ParallelCluster の CloudFormation スタック作成時にも有効なのか検証してみます。
確認してみた
過去にデプロイ済みのスタックが残っていたため、スタックの作成から終了までの時間と、その時と同じクラスターコンフィグを使って新たにデプロイしたスタックの時間を比較してみました。
検証環境
項目 | 値 |
---|---|
AWS ParallelCluster | 3.8.0 |
OS | Ubuntu 22.04 LTS |
CPU Arch | Intel(x86_64) |
HeadNode | t3.micro |
検証に使用したクラスターのコンフィグは以下です。
Region: ap-northeast-1 Image: Os: ubuntu2204 Tags: - Key: Name Value: v380-cluster # ---------------------------------------------------------------- # Head Node Settings # ---------------------------------------------------------------- HeadNode: InstanceType: t3.micro Networking: ElasticIp: false SubnetId: subnet-0c82bb28e119e2aa8 Ssh: KeyName: org-sandbox-keypair LocalStorage: RootVolume: Size: 40 Encrypted: true VolumeType: gp3 Iops: 3000 Throughput: 125 Iam: AdditionalIamPolicies: - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore S3Access: - BucketName: hpc-dev-custom-boostrap-files-for-parallelcluster EnableWriteAccess: false # ---------------------------------------------------------------- # Compute Node Settings # ---------------------------------------------------------------- Scheduling: Scheduler: slurm SlurmSettings: ScaledownIdletime: 5 SlurmQueues: # ------ Test 1 ------ - Name: test1 ComputeResources: - Name: test1 Instances: - InstanceType: t3.micro - InstanceType: t3a.micro MinCount: 0 MaxCount: 10 DisableSimultaneousMultithreading: true ComputeSettings: LocalStorage: RootVolume: Size: 40 Encrypted: true VolumeType: gp3 Iops: 3000 Throughput: 125 CapacityType: SPOT AllocationStrategy: capacity-optimized Networking: SubnetIds: - subnet-0c82bb28e119e2aa8 - subnet-0296a0c8515ed3bdc - subnet-0089ff187d1f54258 PlacementGroup: Enabled: false # CustomActions: # OnNodeConfigured: # Script: s3://hpc-dev-custom-boostrap-files-for-parallelcluster/install/apptainer.sh Iam: AdditionalIamPolicies: - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore S3Access: - BucketName: hpc-dev-custom-boostrap-files-for-parallelcluster EnableWriteAccess: false # ------ Compute 1 ------ - Name: queue1 ComputeResources: - Name: queue1 Instances: - InstanceType: m7i.8xlarge - InstanceType: m7a.4xlarge MinCount: 0 MaxCount: 50 DisableSimultaneousMultithreading: true ComputeSettings: LocalStorage: RootVolume: Size: 40 Encrypted: true VolumeType: gp3 Iops: 3000 Throughput: 125 CapacityType: SPOT AllocationStrategy: capacity-optimized Networking: SubnetIds: - subnet-0c82bb28e119e2aa8 - subnet-0296a0c8515ed3bdc - subnet-0089ff187d1f54258 PlacementGroup: Enabled: false # CustomActions: # OnNodeConfigured: # Script: s3://hpc-dev-custom-boostrap-files-for-parallelcluster/install/apptainer.sh Iam: AdditionalIamPolicies: - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore S3Access: - BucketName: hpc-dev-custom-boostrap-files-for-parallelcluster EnableWriteAccess: false # ---------------------------------------------------------------- # Shared Storage Settings # ---------------------------------------------------------------- SharedStorage: - MountDir: /mnt/hpc-dev-efs-for-parallelcluster Name: efs1 StorageType: Efs EfsSettings: FileSystemId: fs-0846dc947572a66a1 # ---------------------------------------------------------------- # Other Settings # ---------------------------------------------------------------- Monitoring: Logs: CloudWatch: Enabled: true RetentionInDays: 180 DeletionPolicy: "Delete" Dashboards: CloudWatch: Enabled: true
アップデート前
ParallelCluster 3.8 のクラスターを作成したスタックが残っていたため時間を確認しました。pcluster create-cluster
コマンド実行からクラスター作成完了まで約 9 分かかっていました。
項目 | 値 |
---|---|
開始時間 | 2023-12-27 11:59:14 |
終了時間 | 2023-12-27 12:08:13 |
時間差 | 8分59秒 |
アップデート後
同じクラスターのコンフィグを利用して改めて新規のクラスターを作成しました。約 8 分でスタックは完了しました。1分早くなっています。
項目 | 値 |
---|---|
開始時間 | 2024-03-19 12:55:06 |
終了時間 | 2024-03-19 13:03:05 |
時間差 | 7分59秒 |
アップデート後に追加されたイベントを確認
CloudFormation のイベントを確認すると一箇所だけ今回のアップデートから追加されたイベント(CONFIGURATION_COMPLETE
)を確認できました。リソースの作成完了し、安定化(Stabilization
)が進行中である場合に発行されるイベントの様です。
今回のアップデートはこの安定化中に後続の処理を開始するようになったため、以前に比べると前倒しでリソース作成に取りかかれた様子です。最終的にクラスター作成完了まで 1 分短縮に繋がった要因でしょう。
検証結果まとめ
CloudFormation のスタック作成速度向上の影響でクラスターのデプロイ速度が 1 分早くなりました。約 11% の速度向上です。
項目 | 旧 | 現在 | 差分 |
---|---|---|---|
開始時間 | 2023-12-27 11:59:14 | 2024-03-19 12:55:06 | - |
終了時間 | 2023-12-27 12:08:13 | 2024-03-19 13:03:05 | - |
時間差 | 8分59秒 | 7分59秒 | 1分0秒 (現在が早い) |
おわりに
アップデート前に作成してあったスタックでかつ、クラスターのコンフィグが残っているものは 1 件しか手元にありませんでした。何件かあればサンプル数を増やして計測したかったのですが、今となっては検証できなく残念です。